1. Field of the Invention
The present invention generally relates to data processing, and more particularly, to the accessing data through a logical framework.
2. Description of the Related Art
In commonly assigned U.S. patent application Ser. No. 10/083,075 (the '075 application), filed Feb. 22, 2002, entitled “Improved Application Flexibility Through Database Schema and Query Abstraction”, a framework is disclosed for logically/abstractly viewing physical data. The framework of the '075 application provides a requesting entity (i.e., an end-user or application) with an abstract representation of physical data. In this way, the requesting entity is decoupled from the underlying physical data to be accessed. Logical queries based on the framework can be constructed without regard for the makeup of the physical data. Further, changes to the physical data do not necessitate changes to applications accessing the physical data.
However, even an abstract view of an underlying data environment can be complex, in particular when the physical data repository contains large volumes of information that span a number of usage scenarios. For instance, the data warehouse for a large, clinical institution may contain 1000s of fields spanning patient demographic, test and diagnosis information as well as information concerning the operational aspects of the clinic: appointment records, patient loads for physicians and lab test accuracy and turn around time metrics. Representing this environment in a data abstraction model as a set of individual logical fields may be insufficient for a number of usage scenarios. Consider, for example, situations where different user communities have different focus areas of interest. Some users may be solely interested in patients and their records. Others may be concerned with distribution of lab test values or usage data for various types of lab equipment. There may be overlap in the individual fields for each area of interest; however, the method used to correlate data may vary depending on whether the focus is on patient or lab tests. An abstraction model defining individual logical fields may also be insufficient in cases where users are inserting new content or deleting content from the warehouse, for example, adding a new patient to the warehouse or deleting an existing patient from the warehouse. In a basic data abstraction model approach, such as is described in the '075 application, the complete details concerning a patient may be defined by a set of logical fields. Without additional information, it would be difficult, if not impossible, for a user to know which set of logical fields constitutes the concept of a patient. In this case, “patient” represents a higher level view of the information in the warehouse and can be thought of as a composite of individual logical fields defined by the abstract data model. Another limitation of such an abstraction model occurs in situations requiring unique identification of entities in the underlying model. Additional information is required to understand the set of logical fields that together uniquely identify each entity, such as patient, within the underlying data environment. For example, it may be desirable or even required to always include a patient identifier (id) in results of queries designed to return patient information.
Possible solutions to these types of scenarios, would require the user or data access application to have specific knowledge of the make-up of the underlying data environment, enough knowledge to understand what constitutes an entity (such as patient) and how to uniquely identify each entity in the underlying data model. In essence, the application is hard coded to deal with a particular data environment. This approach works if the underlying data environment is static and known in advance, but does not address the more general situation where the data environment is changing over time and/or the situation where the details of the underlying schema are not known in advance. These would be the types of situations that a general purpose, data update and query application would encounter.
Therefore, what is needed is the logical representation of entities defined by one or more logical fields, and in particular a plurality of logical fields.